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Introduction 

The  basic  sequence  numbering  strategy  employed  in  the  ARPA  Internet 
Transmission  Control  Program  (TCP)  is  to  assign  (implicitly)  a sequence 
number  to  each  octet  (8  bit  unit)  of  text  transmitted  in  an  ’ ternet 
packet.  [1,2]  As  explained  in  Tomlinson  and  amplified  by  Dalai  [3,4], 
the  finiteness  of  the  available  sequence  number  space  requires  that  after 
a time,  sequence  numbers  must  be  re-used.  Care  must  be  taken  that  the 
available  sequence  number  space  not  be  used  up  so  fast  that  some  packets 
carrying  old  sequence  numbers  are  still  in  the  network  when  these  numbers 
are  re-used.  To  assure  this,  we  assume  that  packets  can  only  remain  in  the 
network  for  a certain  maximum  lifetime.  The  maximum  rate  at  which  sequence 
numbers  are  used  is  related  to  this  lifetime  and  to  the  size  of  the  sequence 
number  space.  If  the  lifetime  is  T seconds  and  the  maximum  bandwidth 
(rate  of  sequence  number  consumption)  is  B,  octets/second  and  the  size  of 
the  sequence  space  is  S octets,  then  we  must  have  (see  [2]) 

3 > 2-B-T  (1) 

Indeed,  it  may  happen  that  T is  really  a random  variable  without  a guaranteed 
maximum,  in  which  case,  reliability  can  be  improved  by  writing 


S = K-B-T 


(2) 
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which,for  sufficiently  large  K makes  the  probability  nearly  zero  that  two 
packets  carrying  different  text  are  assigned  the  same  or  overlapping  sequence 
numbers.  We  have  chosen  the  following  parameters  for  the  initial  internet 
experiments: 

3? 

S = 2 octets  = sequence  number  space 

1 8 

B = 2 octets/sec  (~2  mbits/second)  = bandwidth 

T = 25  seconds  (~l/2  minute)  = lifetime 

STEP  = 1 second  (=  218  octets) 

We  can  compute  the  minimum  cycle  time  as 

C = S/B  = 2^  sec  (-4.55  hours)  (3) 

Combining  (3)  and  (2),  we  obtain 


K = 


S octets 
B-T  octets 


232 

218  • 25 


= "c  = 512 


(4) 


Even  if  T is  not  bounded  by  2 seconds,  we  can  survive 


T £ 28>23  seconds  = 8192  seconds  = 2.27  hours 


Resynchronization 

Tomlinson  introduces  the  need  to  select  an  initial  sequence  number 
(ISN)  [3]  using  some  well -known,  periodic  value,  such  as  the  time  of  day. 

Figure  1 plots  the  ISN  value  against  time,  where  time  and  ISN  are  measured 
in  the  same  units  (e.g.  using  B as  a parameter). 

The  same  sequence  number  cannot  be  used  to  start  each  a connection,  since 
this  might  introduce  unintentional  duplicate  sequence  numbers.  We  cannot 
rely  on  remembering  the  last  sequence  number  used  on  a given  connection, 
since  this  information  may  have  been  lost  (e.g.  host  failure).  Even  during 
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the  course  of  a particular  connection,  it  may  become  necessary  to 
resyn  Jironize  sequence  numbers  to  avoid  potential  failures.  In  figure 
1,  we  show  the  history  of  sequence  numbers  used  by  a particular  con- 
nection. The  lines  labeled  "ISN"  represent  the  maximum  permitted  rate 
at  which  sequence  numbers  can  be  used.  Suppose  that  the  TCP  supporting 
the  connection  fails  at  "C"  and  must  be  restarted.  Assume,  also,  that 
the  sequence  number  selected  to  restart  is  drawn  from  the  value  of  ISN 
at  the  time  event  "C"  occurred.  The  shaded  area  between  "C"  and  "B" 
represents  the  maximum  expected  time  that  packets  emitted  at  "C"  can 
stay  in  the  net.  Clearly,  the  ISN  line  intersects  this  shaded  area, 
indicating  that,  after  the  restart,  it  is  possible  that  packets  emitted 
at  "C"  may  become  undistinguishable  from  those  potentially  emitted  along 
the  ISN  curve.  To  correct  this  flaw,  the  sequence  number  currently  to 
be  used  on  the  connection  must  be  resynchronized  before  running  intc  the 
forbidden  zone  to  the  left  of  the  ISN  line. 

Testing  for  the  Need  to  Resynchronize 

As  packets  are  produced  and  sequence  numbers  assigned  to  them,  the 
TCP  must  check  for  two  possible  conditions  which  indicate  that  resyn- 
chronization is  needed.  The  first  is  that  sequence  numbers  are  being 
used  up  so  fast  that  they  advance  faster  than  ISN.  The  other  is  that 
they  advance  so  slowly  that  ISN  "catches  up  with  them." 

The  basic  method  of  selecting  an  initial  sequence  number  is  to  delay 

for  an  arbitrary  period  labelled  a "clock  tick"  and  then  select  the  new 

ISN.  In  the  TCP  implementation,  this  amounts  to  one  second  of  time  during 
1 

which  up  to  2 octets  may  be  transmitted.  In  figure  2,  three  sequence 
number  histories  are  traced,  ending  in  points  "A",  "B",  and  "C".  In  the 


c 


Figure  2 

Detecting  the  Forbidden  Zone 
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trace  labelled  "A,"  sequence  numbers  are  used  at  such  a rate  that  point 
"An  lies  beyond  ISN  plus  one  step  (clock  tick).  If  the  connection  were 
to  fail  and  be  restarted  at  "A,"  the  new  ISN  would  be  just  below  point  "AM 
and  would  introduce  potential  unwanted  duplicates. 

This  situation  can  be  detected  before  transmission  of  the  packet. 

Let  SEQ  represent  the  proposed  sequence  number  of  the  packet,  and 
SEQ+L-1  be  the  sequence  number  implicitly  associated  with  the  last  octet 
of  packet  data,  if  ISN+STEP  (at  the  moment  that  SEQ  is  to  be  assigned) 
lies  in  the  range  [SEQ,  SEQ+L-1],  then  the  type  "A"  ISN  failure  is 
about  to  occur.  The  solution  is  to  send  only  as  much  text  as  is  allowed 

(which  does  not  result  in  the  failure)  and  wait  for  the  clock  to  tick 

again. 

The  situation  in  curve  "B"  is  quite  different.  In  this  case,  the 
connection  is  using  sequence  numbers  so  slowly  that  the  forbidden  zone 
preceding  the  ISN  curve  has  advanced  and  run  into  the  connection  sequence 
number  curve.  There  are  two  solutions.  One  is  to  wait  for  the  packet 
lifetime  plus  one  clock  step  to  expire  (in  which  case,  the  sequence  history 
will  pop  out  of  the  forbidden  zone  again.  The  other  is  to  actively  resyn- 
chronize the  connection.  The  test  for  the  type  "B"  situation  is  whether 

sequence  number  SEQ  lies  in  the  range  [ISN,  ISN+T+STEP]  or 
[ISN,  ISN+33-218]. 

32 

Note  that  all  tests  for  inclusion  must  be  modulo  S(2  ) to  account 

for  the  wraparound  of  sequence  numbers. 

Curve  "C"  in  figure  2 shows  a sequence  number  trace  which  tends,  on 
the  average,  to  lie  within  legal  values  at  all  times. 
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Conclusions 

The  value  of  clock  step  may  be  arbitrarily  small,  depending  on  the 

desired  delay  overhead  to  wait  for  the  tick. 

Checking  for  resynchror  ization  is  simple: 

if  SEQ  e [1SN,  ISN+T+STEP]  then  resynchromze. 

if  1SN+5TEP  c [SEQ,  SEQ+L-1]  (where  L = packet  length  in  octets) 

then  wait  for  clock  to  tick. 
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Appendix  A - Window  Size 

There  is  a relationship  between  window  size  and  the  other  quantities 
discussed  in  this  paper.  Let  us  call  the  average  round-trip  delay  in 
the  network  D (measured  so  as  to  include  the  delay  at  the  destination 
for  accepting  a packet  and  producing  an  acknowledgment).  Maximum  band- 
width cannot  be  achieved  in  this  system  unless  the  source  is  permitted 
to  transmit  contirusously  until  receiving  an  acknowledgment.  This  leads 
to  the  relationsnip 

W>8  D = 2^  octets/second  • D second  (5) 


However,  we  have  arbitrarily  limited  W to  2^  octets,  which  means  that 


D must  be  bounded 
J6 


D — -To-  seconds  = .250  seconds 

2 1 o 


(6) 


This  is  not  unrealistic  for  a ground  based  network,  but  is  inadequate 
for  a satell  i te-bas:  d netwoi  '*  where  D>.5  sec  (the  result  of  a minimum 
89,600  mile  round-trip  in  space:  89,600/186,200  = .48  seconds). 

In  the  Arpanet,  the  average  line  capacity  is  50  kbit/sec,  of  which 
only  about  48kbit/sec  or  6k  octets/sec  are  available  to  the  host/host 
protocol.  Since  W measures  permission  to  transmit  data,  we  can  further 
reduce  effective  bandwidth  by  a minimum  overhead.  The  TCP  header  length 
is  currently  40  octets  (32  are  defined  in  reference  1;  4 more  are  needed 
for  the  ARPANET  leader,  and  4 more  are  currently  used  for  a timestamp).  In 
the  best  case,  an  ARPANET  message  can  be  8096  bits  (1012  octets)  including 
leader,  so  the  overhead  factor  is  40/1012  = 4%. 
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Using  5.76  k octets/sec  for  B in  equation  5 we  obtain 

W £ 5.76  k octets/sec*D  (5) 

and,  since  W = 2^  octets, 

D£  216/5,760  sec  = 11.4  sec  (6) 

This  compares  favorably  with  measured  ARPANET  delays  which  average 
less  than  0.5  seconds  [7]. 


-8- 


References 

1.  Cerf,  V.,  Y.  Dalai,  C.  Sunshine,  "Specification  of  Internet 
Transmission  Control  Program,"  INWG  General  Note  #72, 

December  1974  (revised). 

2.  Cerf,  V.  and  R.  Kahn,  "A  Protocol  for  Packet  Network  Intercommunication," 
IEEE  Transactions  on  Communication,  Vol  C0M-20,  No.  5,  May  1974. 

3.  Tomlinson,  R. , "Selecting  Sequence  Numbers,"  INWG  Protocol  Note  #2, 
September  1974. 

4.  Dalai,  Y.  "More  on  Selecting  Sequence  Numbers,"  INWG  Protocol  Note  #4, 
October  1974. 

5.  Belsres,  D. , "On  Single  Message  Communication,"  INWG  Protocol  Note 
£3,  September  1974. 

6.  Retz,  D.  and  V.  Cerf,  "Station-Packet  Radio  Protocol,"  PRTN  #160 
December  19,  1975. 

7.  Kleinruck,  L.  and  W.  Naylor,  "On  Measured  Behavior  of  the  ARPANET," 
Network  Measurement  Note  #18,  NIC  #20793,  February  1974. 

8.  Kleinrock,  L.,  W.  E.  Naylor,  H.  Opderbeck,  "A  Study  of  Line  Overhead 
in  the  ARPANET,"  CACM,  Vol.  19,  No.  1,  January  1976,  pp.  3-13. 


distribution 


ARPA 


Director  (2  copies) 

ATTN:  Program  Management 

Advanced  Research  Projects  Agency 
1400  Wilson  Boulevard 
Arlington,  VA  22209 


ARPA/IPT 

1400  Wilson  Boulevard 
Arlington,  VA  22209 

Dr.  Robert  Kahn 
Mr.  Steven  Walker 


Bell  Laboratories 

Dr.  Elliot  N.  Pinson,  Head 
Computer  Systems  Research  Dept. 
Bell  Laboratories 
600  Mountain  Avenue 
Murray  Hill,  New  Jersey  07974 

Dr.  Samuel  P.  Morgan,  Director 
Computing  Science  Research 
Bell  Laboratories 
610  Mountain  Avenue 
Murray  Hill,  New  Jerse)  07974 

Dr.  C.  S.  Roberts,  Head 
The  Interactive  Computer  Systems 
Research  Department 
Beil  Laboratories 
Holmdel , New  Jersey  07733 

Bolt  Beranek  and  Newman  Inc. 

50  Moultor.  Street 
Cambridge,  Massachusetts^  02138 

Mr.  Jerry  D.  Burchfiel 
Mr."  R.  Clements 
Mr.  A.  McKenzie 
Mr.  J.  McQuillan 
Mr.  R.  Tomlinson 
Mr.  D.  Walden 


Burroughs  Corporation 

Dr.  Wayne  T.  Wilner,  Manager 
Burroughs  Corporation 
3978  Sorrento  Valley  Boulevard 
San  Diego,  CA  92121 


Mr.  David  H.  Da hm 
Burroughs  Corporation 
Burroughs  Place 
P.  0.  Box  418 
Detroit,  MI  48232 

Mr.  B.  A.  Creech,  Manager 
New  Product  Development 
Burroughs  Corporation 
460  Sierra  Madre  Villa 
Pasadena,  CA  91109 


Cabledata  Associates 

Mr.  Paul  Baran 
Cabledata  Associates,  Inc. 
701  Welch  Road 
Palo  Alto,  CA  94304 


California,  University  - Irvine 

Prof.  David  J.  Farber 
University  of  California 
Irvine,  CA  92664 


California,  University  Los  Angeles 

Professo)  Gerald  Estrin 
Computer  Sciences  Department 
School  of  Engineering  and  Applied  Sci 
Los  Angeles,  CA  90024 

Professo*  Leonard  Kleinrock 
University  of  California 
3732  Boelter  Hall 
Los  Angeles,  CA  90024 

Mr.  William  E.  Naylor 
University  of  California 
3804-D  Boelter  Hall 
Los  Angeles,  CA  90024 


Collins  Radio  Group 
1200  N.  Alma  Road 
Richardson,  Texas  75080 

Mr.  Don  Heaton 
Mr.  Frederic  Weigl 


Defense  Communications  Engineering 
Center 

Dr.  Harry  Helm 
DCEC , R- 520 
1860  Wiehle  Avenue 
Reston,  VA  222090 


General  Electric 


Dr.  Richard  L.  Shuey 
General  Electric  Research 
and  Development  Center 
P.  0.  Box  8 

Schenectady,  New  York  12301 

Dr.  A.  Bell  Isle 
General  Electric  Company 
Electronics  Laboratory 
Electronics  Park 
Syracuse,  New  York  13201 

Mr.  Ronald  S.  Taylor 
General  Electric  Company 
175  Curtner  Avenue 
San  vlose,  CA  95125 


General  Motors  Corporation 
Computer  Science  Department 
General  Motors  Research  Laboratories 
General  Motors  Technical  Center 
Warren,  MI  48090 

Dr.  George  C.  Dodd,  Assistant  Head 
Mr.  Fred  Krull,  Supervisory  Research 
Engineer 

Mr.  John  Boyse,  Associate  Senior 
Research  Engineer 


Hawaii , University  of 
The  ALOHA  System 
2540  Dole  Street,  Holmes  486 
Honolulu,  Hawaii  96822 

Professor  Norman  Abramson 


Hughes  Aircraft  Company 

Mr.  Knut  S.  Kongelbeck,  Staff  Engr. 
Hughes  Aircraft  Company 
8430  Fall  brook  Avenue 
Canoga  Park,  CA  91304 

Mr.  Allan  J.  Stone 
Hughes  Aircraft  Corporation 
Bldg.  150  M.S.  A 222 
P.  0.  Box  90515 
Los  Angeles,  CA  90009 

Hughes  Aircraft  Company 
Attn:  B.  W.  Campbell  6/E110 

Company  Technical  Document  Center 
Centinela  and  Teale  Streets 
Culver  City,  CA  90230 


IBM 


Dr.  Patrick  Mantey,  Manager 
User  Oriented  Systems 
International  Business  Machines  Corp. 
K54-282,  Monterey  and  Cottle  Roads 
San  Jose,  CA  95193 

Dr.  Leonard  Y.  Liu,  Manager 
Computer  Science 

International  Business  Machines  Corp. 
K51-282,  Monterey  and  Cottle  Roads 
San  Jose,  CA  95193 

Mr.  Harry  Reinstein 
International  Business  Machines  Corp. 
1501  California  Avenue 
Palo  Alto,  Ca  94303 


Illinois,  University  of 

Mr.  John  D.  Day 
University  of  Illinois 
Center  for  Advanced  Computation 
114  Advanced  Computation  Bldg. 
Urbana,  Illinois  61801 


Institut  de  Recherches  d Informatique  et 
d'Automatique  (IRIA) 

Reseau  Cyclades 
78150  Rocquencourt 
France 


B 


Mr.  Louis  Pouzin 
Mr.  Hubert  Zimmerman 


Information  Sciences  Institute, 
University  of  Southern  California 
4676  Admiralty  Way 
Marina  Del  Rey,  CA  90291 

Dr.  Marty  J.  Cohen 
Mr.  Steven  D.  Crocker 
Dr.  Steve  Kimbleton 
Mr.  Keith  Uncapher 


London,  University  College 

Professor  Peter  Kirstein 
UCL 

Department  of  Statistics  & 
Computer  Science 
43  Gordon  Square 
London  WC1H  OPD,  England 


Massachusetts  Institute  of  Technology 

Dr.  J.  C.  R.  Licklider 
MIT 

Project  MAC  - PTD 
545  Technology  Square 
Cambridge,  Massachusetts  02139 


MITRE  Corporation 

Mr.  Michael  A.  Padlipsky 
MITRE  Corporation 

1320  Dolly  Madison  Blvd. 
Westgate  Research  Park 
McLean,  VA  22101 


Network  Analysis  Corporation 
Beechwood,  Old  Tappan  Road 
Glen  Cove,  New  York  11542 

Mr.  Wushow  Chou 
Mr.  Frank  Howard 


National  Bureau  of  Standards 

Mr.  Robert  P.  Blanc 
National  Bureau  of  Standards 
Institute  for  Computer  Sciences 
and  Technology 
Washington,  D.  C.  20234 

Mr.  Ira  W.  Cotton 

National  Bureau  of  Standards 

Building  225,  Room  B216 

Washington,  D.  C.  *0234  r 


National  Physical  Laboratory 
Computer  Science  Division 
Teddington,  Middlesex,  England 

Mr.  Derek  Barber 
Dr.  Donald  Davies 
Mr.  Roger  Scant lebury 
Mr.  P.  Wilkinson 


National  Security  Agency 
9800  Savage  Road 
Ft.  Meade,  MD  20755 

Mr.  Dan  Edwards 
Mr.  Ray  McFarland 


Norwegian  Defense  Research  Establishment 

P.  0.  Box  25 

2007  Kjeller,  Norway 

Mr.  Yngvar  G.  Lundh 
Mr.  P.  Spilling 


Oslo,  University  of 

Prof.  Dag  Belsnes 
EDB-Sentret,  University  of  Oslo 
Postbox  1059 

Blindern,  Oslo  3,  Norway 


Rand  Corporation 
1700  Main  Street 
Santa  Monica,  CA  90406 

Mr.  S.  Gaines 
Mr.  Carl  Sunshine 


Rennes,  University  of 

M.  Gerard  LeLann 
Reseau  CYCLADES 
U.E.R.  d' Informatique 
B.  P.  25A 

35031 -Rennes-Cedex,  France 


Stanford  Research  Institute 
333  Ravenswood  Avenue 
Menlo  Parkv  CA_94025_. 

Ms.  E.  J.  Feinler 
Augmentation  Research  Center 

Or.  Jon  Postel 

Augmentation  Research  Center 

Mr.  D.  Nielson  Director 
Telecommunication  Sciences  Center 

Dr.  David  Retz 

Telecommunication  Sciences  Center 


SystcH^  Development  Corpora ti on 
Dr.  G.  D.  Cole 

System  Development  Corporation 
2500  Colorado  Avenue 
Santa  Monica,  CA  90406 


Telenet  Communications,  Inc. 

1666  K Street,  NW 

Wasni ngton,  D.  C.  2QQQ6 

Dr.  Holger  Opderbeck 
Dr.  Lawrence  G.  Roberts 
Dr.  Barry  Wessler 


T ransaction  Tech no 1 ogy  Inc. 

Dr.  Robert  Metcalfe 
Director  cc  Technical  Planning 
Transaction  Technology  Inc. 
10080  Nil  shire  Blvd. 

Los  Angeles,  CA  90024 


Xerox  Palo  Alto  Research  center 

3333  Coyote  Hill  Road 

Palo  Alto,  CA  94304 

Mr.  David  Boggs 

Dr.  William  R.  Sutherland 


STANFORD  UNIVERSITY 

Digital  Systems  Laboratory 

Mr.  Ronald  Crane 
Mr.  Yogen  Dalai 
Ms.  Judith  Estrin 
Professor  Michael  Flynn 
Mr.  Richard  Karp 
Mr.  James  Mathis 
Mr.  Darryl  Rubin 
Mr.  Wayne  Warren 

piqi  tal  Systems  L a b o r a t ory_  P j ^-n 

Computer  Science  Department  - 1 copy 
Computer  Science  Library  - 2 copies 

Digital  Systems  Laboratory  Library  - 6 copies 
Engineering  Library  - 2 copies 
IEEE  Computer  Society  Repository  - 1 copy 

Electrical  Engineering 

Dr.  John  Linvill 


Defense  Communication  Agency 

Dr.  Franklin  Kuo 
4819  Reservoir  Drive 
Washington,  D.  C.  20007 


D 


